User Interface Apparatus and Methods

ABSTRACT

In one aspect, the invention provides a digital data processing system for information storage and retrieval that includes a first digital data processor (e.g., personal computer, workstation, server, mainframe, etc.) coupled to a second digital data processor and a data store (e.g., a RDF data store, relational database, etc.). The first digital data processor creates, reads, updates and/or deletes data from the data store (i.e., “CRUD” operations) based on a model generated by the first digital data processor. The model comprises an ontology and a set of constraints that are applied to data characterized by the ontology.

This application claims the benefit of priority of U.S. PatentApplication Ser. No. 61/104,211 filed Oct. 9, 2008, having the sametitle hereof, the teachings of which are incorporated herein byreference.

BACKGROUND OF THE INVENTION

The invention pertains to digital data processing and, moreparticularly, to methods and apparatus for facilitating digital datainformation storage and retrieval operations, e.g., data create, read,update, and delete operations.

In today's marketplace, many advanced data management systems focus onproviding back-end support for data storage and retrieval. They aregenerally geared towards developers, who use Application ProgrammingInterfaces (APIs) supplied with the packages to write “one-off”applications (e.g., with Java Swing) that permit users to create,access, delete and otherwise “interface” with the data. While thisfacilitates (and, indeed, necessitates) customization, a drawback isincreased time and expense at inception and throughout the lifetime ofeach custom application. This has led to slow adoption of many advanceddata management technologies by business enterprises and the like.

One advanced data management technology that is coming to the fore issemantic data management. These are technologies that utilize knowledgespace-specific vocabularies to improve data retrieval, if not also datastorage. In addition to the hurdles discussed above, however, currentsemantic data packages typically do not provide security featuresdesired by many enterprises (e.g., financial institutions). The packagesfocus, instead, on improving data retrieval and, as a consequence,necessitate increased attention to security by application developers.

An object of the invention is to provide improved methods and apparatusfor digital data processing.

A further object of the invention is to provide such methods andapparatus as facilitate digital data information storage and retrieval.A related object of the invention is to provide such methods andapparatus as facilitate data creation, retrieval, update and deletion(“CRUD”) operations.

A further related object is to provide such methods and apparatus asfacilitate the development and life-time maintenance of data managementapplications.

A still further object of the invention is to provide such methods andapparatus as ensure data security.

A yet still further object of the invention is to provide such methodsand apparatus as are adapted for use with semantic data systems, as wellas other advanced data technologies.

SUMMARY OF THE INVENTION

The foregoing objects are among those attained by the invention whichprovides, in one aspect, a digital data processing system forinformation storage and retrieval that includes a first digital dataprocessor (e.g., personal computer, workstation, server, mainframe,etc.) coupled to a second digital data processor and a data store (e.g.,a RDF data store, relational database, etc.). The first digital dataprocessor creates, reads, updates and/or deletes data from the datastore (i.e., “CRUD” operations) based on a model generated by the firstdigital data processor. The model comprises an ontology and a set ofconstraints that are applied to data characterized by the ontology.

In related aspects, the invention provides a digital data processingsystem for information storage and retrieval as described above in whichthe first digital data processor displays a user interface (UI) forperforming CRUD operations. In further related aspects, the inventionprovides such a digital data processing system in which the UI is basedon the model and code generated therefrom, e.g., by the first digitaldata processor and/or the second digital data processor. In stillfurther related aspects, the invention provides such a digital dataprocessing system in which the UI includes a plurality of data fields,each data field associated with one or more data labels (e.g., “SSN”)and one or more data values (e.g., “0000000000”).

In related aspects, the invention provides a digital data processingsystem for information storage and retrieval as described above in whichthe set of constraints include, for example, security rules (e.g.,denying or allowing selected CRUD operations), validators (e.g.,defining a minimum and/or maximum length for a data value, definingpermissible data value character types), default values (e.g., “0,”NULL, etc.), field masking (e.g., only transmitting the last 4 digits ofa social security number for display in the UI).

In related aspects, the invention provides a digital data processingsystem for information storage and retrieval as described above in whichthe data labels are defined by the ontology and the data values aredefined by any of the model (e.g., according to a default valueconstraint), and the first digital data processor (e.g., in response toa CRUD operation performed via the UI).

In related aspects, the invention provides a digital data processingsystem for information storage and retrieval as described above in whichthe second digital data processor masks a selected portion of one ormore data values prior to generation and display of the UI on the firstdigital data processor, wherein said masking is based on one or moreconstraints defined in the model. In further related aspects, theinvention provides a digital data processing system for informationstorage and retrieval as described above in which the first digital dataprocessor generates a UI that displays portions of the data values thatare not masked, and does not display the masked portions of said datavalues.

In related aspects, the invention provides a digital data processingsystem for information storage and retrieval as described above in whichthe first and/or second digital data processors generate a warning inresponse to user-input entered via the first digital data processor. Infurther related aspects, the invention provides a digital dataprocessing system as described above in which the warning is generatedin accord with the one or more constraints defined by the model (e.g.,minimum or maximum data value length). In still further related aspects,the invention provides a digital data processing system as describedabove in which the first digital data processor displays said warning toa user and/or administrator.

In related aspects, the invention provides a digital data processingsystem for information storage and retrieval as described above in whichthe second digital data processor displays a UI for defining theconstraints of the model. For example, the UI may include a serious ofmenus, check boxes, fields, etc., for creating, customizing, andassociating security rules, default values, validators, and fieldmasking constraints with data characterized in the ontology.

Still other aspects of the invention provide methods paralleling theoperations described above.

These and other aspects of the invention are evident in the drawings andtext that follows.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the invention may be attained byreference to the drawings, in which:

FIG. 1 depicts a digital data processing system and environment of thetype used in practice of the invention;

FIGS. 2A-2E depict developer-side user interface (UI) displays, e.g.,for defining a digital data storage and retrieval system that providesCRUD capabilities;

FIGS. 3A-3E depict client-side user interface (UI) displays, e.g., forperforming CRUD or other digital data storage and retrieval operations;and

FIG. 4 depicts an operation of a system for storing and retrievingdigital data (e.g., RDF data or otherwise) according to one practice ofthe invention.

DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENT

FIG. 1 depicts a digital data processing system and environment forstoring and retrieving digital data (e.g., RDF or other semantic data)according to one practice of the invention. This can include, forexample, creating, reading, updating and deleting (CRUD) data from adata store via a Graphical User Interface (GUI), or other User Interface(UI), e.g., command-line, etc. In the illustrated embodiment, the systemincludes digital data processors 20-50, which may be personal computers,workstations, mainframes, or other digital data processing apparatus ofthe type known in the art capable of executing applications, programsand/or processes. Although digital data processors 20-50 are shown here,those skilled in the art will appreciate that in other embodiments thesystem may include a greater or lesser number of such digital dataprocessors.

Illustrated digital data processors 20-50 execute in a networkenvironment. In other embodiments, digital data processors 20-50 mayoperate alone or in other environments, networked or otherwise. In anyevent, illustrated digital data processors 20-50 are coupled to eachother, as shown, via a network 70, such as the Internet, a local-areanetwork (LAN), wide-area network (WAN), or otherwise, that may bepublic, private, IP-based, etc.

In a typical embodiment, illustrated here, digital data processor 20comprises a personal computer, workstation, mainframe, or other digitaldata processing apparatus, as discussed above, and is used by adeveloper or analyst (collectively, “analyst), to build, test, anddeploy a software platform providing CRUD editing capabilities to aclient 30, as discussed further below. The digital data processor 20executes a variety of applications for creating such a platform,including, for example, an ontology editor 21 and a semantic editingframework (SEF) 23. The illustrated ontology editor 21 creates anontology 22 (e.g., either automatically or via analyst input) thatdefines a structure of data (e.g., RDF data stored in data store 60,discussed below). This may include a text editor, aninterpreter/compiler, libraries, or otherwise—all of the type known inthe art, albeit as adapted in accord with the teachings hereof. In theillustrated embodiment, the editor 21 creates the ontology 22 with theWeb Ontology Language (OWL), although in other embodiments the editor 21may use other ontology-definition languages, as well.

The illustrated SEF 23 defines (e.g., via analyst input) user roles(e.g., Supervisor, Analyst, Administrator, etc.), security rules,validators, default values, field masking, and/or other constraints 24(collectively, “constraints”) that are applied to data characterized bythe ontology 22. In the illustrated embodiment, the constraints 24 aredefined in XML, although in other embodiments it may be otherwise. TheSEF 23 generates a semantic model 25 (or simply, “model”) by combiningthe ontology 22 and constraints 23 into a cohesive file (or set offiles). Accordingly, in the illustrated embodiment, the model 25 is the“foundation” for providing CRUD capabilities to the client 30, asdiscussed further below. The SEF 23 also generates client code 26 (e.g.,Adobe Flex) for creating the client interface 31, and the database code27 which facilitates interaction between the digital data processor 50(discussed below) and the data store 60 (discussed below).

Illustrated digital data processor 30 comprises a personal computer,workstation, mainframe, or other digital data processing apparatus, asdiscussed above, and is used by a client to interface with stored data(e.g., RDF or otherwise). In the illustrated embodiment, the client 30provides an interface 32 (e.g., graphical or otherwise) for interactingwith data in the data store 60. By way of non-limiting example, theclient 30 provides operations for creating, reading, updating and/ordeleting data (CRUD) in the data store 60, although the client 30 mayprovide other operations, as well. In the illustrated embodiment, theinterface 32 is generated from UI code 33 comprising the client code 26,HTML, and other web technologies known in the art, such as JavaScript,etc, although in other embodiments it may be otherwise.

The digital data processor 40 (or “UI server) comprises a personalcomputer, workstations, mainframe, server, or other digital dataprocessing apparatus. In the illustrated embodiment, the digital dataprocessor 40 generates the UI code 33 that displays the UI 32 on theclient device 30. In the illustrated embodiment, the data processor 40generates the code 33 from the model 25 and the client code 26, andcomprises a combination of Adobe Flex code, and HTML, JavaScript, XML,etc., although it may also include other components instead of, or inaddition to the aforementioned technologies (e.g., programminglibraries, modules, etc.). Although in the illustrated embodiment, thedata processor 40 generates the UI code 33, in other embodiments thedata processor 20 may generate such code 33 itself, e.g., via the SEF23, and the data processor 40 may only store and execute that code 33without the model 25.

As discussed above, the digital data processor 40 executes in a networkenvironment, e.g., in communications coupling with digital dataprocessors 20-30 and 50 via the LAN/WAN 70. In the illustratedembodiment, the digital data processor 40 executes behind one or morefirewalls 41 and 42 of the type conventionally known in the art ofdigital network security. The firewalls 41 and 42 themselves maycomprise software executing on the digital data processor 40, or theymay execute on dedicated appliances (e.g., one or more digital dataprocessors). In any event, the firewalls 41 and 42 regulate trafficbetween and among the digital data processors 20-50, e.g., in order toprevent unauthorized access to the digital data processor 40. Thus, forexample, the firewalls 41 and 42 may be configured by the analyst topermit, deny, encrypt, decrypt, or proxy network traffic betweendifferent security domains based upon a set of rules and/or otherconstraints (e.g., as defined in the model 25, or otherwise). Althoughfirewalls are shown here, those skilled in the art will appreciate thatsystems according to the invention may employ a wide range of securitymeasures of the type commonly known in the art of information security(e.g., physical security, authentication systems, anti-virus software,etc.), albeit as adapted in accord with the teachings hereof.

The illustrated digital data processor 50 (or “Database Server”)comprises a personal computer, workstation, mainframe, server, or otherdigital data processing apparatus, that executes a digital datainformation storage and retrieval application (e.g., a databasemanagement system). The data processor 40 stores, retrieves, updates,deletes, and otherwise interfaces with data maintained on networkedattached storage device 60. In the illustrated embodiment, the datastore 60 comprises a hard disk drive and/or other persistent storagedevice of the type known in the art. By way of non-limiting example, thestorage device (or “data store”) 60 stores data (e.g., RDF or otherwise)for retrieval and display by the digital data processors 30 and 40.

FIG. 2A-2E depict an exemplary user interface display 100 for the SEF 23that allows a user (e.g., analyst, developer, administrator, etc.) tocreate, customize and associate the constraints 24 with the datacharacterized in the ontology 22. In the illustrated embodiment, the SEF23 will generate the model 25, and the code associated therewith (e.g.,client code 26, database code 27, etc.), from the ontology 22 andconstraints 24. In other embodiments, a user may bypass the SEF display100 altogether and manually code the constraints 24 to add or customizeconstraints as necessary. FIG. 2A-2E further depict exemplary code“snippets” 22 a and 24 a from the ontology 22 and constraints 24 whichreflect a current display state of the UI 100. More particularly, asconstraints are added, as illustrated in FIGS. 2A-2E, the constraintsfile 24 a is updated to contain the SEF-generated code for thoseconstraints. Associated FIGS. 3A-3E depict exemplary client userinterface displays 32 corresponding to the SEF interface displays 100 ofFIGS. 2A-2E. More specifically, FIG. 3A corresponds to FIG. 2A, FIG. 3Bcorresponds to FIG. 2B, and so on and so forth.

By way of overview, the ontology 22 is defined with OWL, as mentionedabove, a portion of which is shown here (22 a). OWL uses an RDF/XMLsyntax to define a set of “classes” (e.g., “Person”) that each haveassigned “properties” (e.g., “SSN”). However, those skilled in the artwill appreciate that classes and properties are specific to an OWLimplementation of the ontology 22, and in other embodiments, theontology 22 may be implemented otherwise.

Also as discussed above, and again by way of of overview, theconstraints 24 are defined in XML, a portion of which is shown here (24a), although in other embodiments, the constraints may be definedotherwise. Those skilled in the art will appreciate that the ontology 22a, constraints 24 a, and display 100 illustrated here are shown only byway of example, and other embodiments may be implemented otherwise(e.g., without properties or classes), or without ontologies at all(e.g., the system may use another semantic definition structure).

FIG. 2A, more particularly, depicts an exemplary SEF 23 user interface100 displayed on the digital data processor 20 used for customizing andgenerating the model 25. In the illustrated embodiment, shown here, ananalyst may add, remove, update, or otherwise define constraints via aset of graphical menus 110-170, and the SEF 23 generates code 24 acorresponding to those constraints. As discussed above, and below, thoseconstraints can include, for example, default values 140, field masking150, validators 160, and security rules 170, just to name a few. Thoseskilled in the art will appreciate that menus 110-170, as well as thecode 22 a and 24 a, are shown merely by way of example, and in practiceof the invention, the system may include many different configurationoptions (e.g., pre-defined in the system package, defined by a developerduring the initial system deployment, and/or by a client after thesystem has been deployed).

Although not illustrated here, the SEF 23 may also define user roles(e.g., Supervisor, Analyst, etc.), and assign each role a selected“privilege” level. By way of non-limiting example, a Supervisor may havea higher privilege level than an Analyst. In the illustrated embodiment,user roles are often associated with constraints (e.g., security rules,field masking, etc.), as discussed further below. Thus, by way ofnon-limiting example, the SEF 23 may define a constraint that allows aSupervisor, but not an Analyst, to perform update operations.

As shown here, by way of example, the display 100 is divided into tworegions (i.e., a top region and a bottom region). The top regionincludes a property field 110, label field 120, and type field 130.Those skilled in the art will appreciate that the illustrated display100 is shown merely by way of example, and other embodiments may use adifferent display (e.g., an undivided display, a display with three ormore regions, etc.), or no display at all (e.g., an analyst may edit themodel directly by hand-coding the constraints 22).

In the illustrated embodiment, the property field 110 displays thenamespace and name of the selected property (e.g., “http:// . . ./#ssn,” as shown by way of non-limiting example) defined in theconstraints 22 a (e.g., via an analyst using the SEF UI 100). The labelfield 120 comprises a configurable field used to set the field name(e.g., “SSN,” as shown by way of non-limiting example) that will displayon the client interface 32. The type field 130 is a configurable field(e.g., via a “drop down” selection box, as shown) that sets the datatype of the field, e.g., “string” (as shown by way of non-limitingexample), boolean, data, or float, just to name a few. In theillustrated embodiment the type field 130 is typically populated fromthe ontology 22, but it may also be manually set, e.g., by the analyst.Those skilled in the art will appreciate that fields 100-130 are shownby way of example, and in practice may include other fields, selectionboxes, checkboxes and otherwise, e.g., as specified by the ontology 22,constraints 24, or otherwise.

The bottom region of display 100 provides configuration menus fordefining the constraints 24. The display 100 includes a default factorymenu 140, data processor menu 150, validator menu 160, and securityrules menu 170, although in practice of the invention, a greater orlesser number of menus may be displayed. As shown in FIG. 2B, by way ofnon-limiting example, the user has chosen to constrain the property“http:// . . . #ssn” having the label “SSN” as having a “string” value.Also as shown, the SEF 23 has generated the corresponding code 24 forthat constraint. Again, the display 100 and constraint code 24 a areshown by way of non-limiting example and may vary in practice (e.g., thegenerated code may be in a markup language other than XML, etc.).

FIG. 2B depicts the display 100, generally as described above, furtherincluding a default factory constraint 141 defined in the defaultfactory menu 140. The default factory constraint 141 effectively sets astatic default value for a selected property (e.g., “http:// . . .#ssn”). More specifically, the constraint 141 specifies that theselected property has a fixed default value, e.g., “000000000.” The SEF23 will subsequently generate the code 24 a that will instruct theclient 30 to display a default value of “000000000” for this property inthe corresponding field 32 a of the UI 32. See FIG. 3B. Those skilled inthe art will appreciate that in practice of the invention, other defaultvalues may be defined instead of, or in addition to, the illustrateddefault value, shown by way of non-limiting example.

FIG. 2C depicts the display 100, generally as described above, furtherincluding a data processor 151 defined in the data processor menu 150.The specified data processor 151 applies a character masking constraintto the selected property (e.g., “http:// . . . #ssn”). In theillustrated embodiment, selecting “mask” instructs the SEF 23 togenerate code that, when executed by the digital data processor 40 (orother apparatus that generates the UI 32), will hide the property'svalue in the UI 32 and enter a mask character that will display in theUI (e.g., an asterisk). See FIG. 3C. Properties can be assigned a numberof different masking settings that will be applied based upon the roleassigned to the user viewing the field. By way of non-limiting example,a data processor could be defined to allow a “supervisor” to see more ofdata (e.g., a social security number) than an “analyst,” or to maskadditional characters when performing an specific operations.

Generally, masking is performed by entering into the UI 100 the numberof characters that should be masked at the start and end of the selectedfield, and by selecting the role(s) that the mask should apply to. Inthe illustrated embodiment, a blank start and/or end values are assumedas zeroes, and a blank role entry will apply the mask to all roles,although in other embodiments it may be otherwise. Moreover, if a user'srole matches multiple entries in the list of masks for a selectedproperty, then the first mask in the list will be applied. In theillustrated embodiment, masking is based on the role of the user, andthat the system will always mask according to the most restrictive roleadded, although in other embodiments this may vary.

Those skilled in the art will appreciate that in practice of theinvention, other data processors may be defined instead of, or inaddition to, the illustrated masking data processor, shown by way ofnon-limiting example.

FIG. 2D depicts the display 100, generally as described above, furtherincluding a validator constraint 161 defined in the validator menu 160.In the illustrated embodiment, the constraint 161 allows a user tocreate an integer definition for validation that can be set with minimumor maximum values for a selected property. Thus, as shown by way ofnon-limiting example, the selected property (e.g., social securitynumber) must have a minimum length of nine characters and maximum lengthof nine characters, i.e., effectively requiring a nine-digit entry. Byway of further example, the SEF 23 will generate code 24 a that, whenexecuted by the digital data processor 40, will instruct the client 30to display a UI 32 that requires a nine-digit entry in the selectedproperty field 32 a. See FIG. 3D. Those skilled in the art willappreciate that in practice of the invention, other validators may bedefined instead of, or in addition to, the illustrated validator, shownby way of non-limiting example.

FIG. 2E depicts the display 100, generally as described above, furtherincluding a security rule constraint defined in the security rules menu170. In the illustrated embodiment, a security rule can be set by userrole and/or by operation (e.g., create, read, update, delete, etc.). Asshown, by way of non-limiting example, a user can define a constraint(e.g., via pop-window 171 or otherwise) that specifies that Analysts arenot allowed to perform update operations. By way of further example, theSEF 23 will generate code 24 a that, when executed by the digital dataprocessor 40, will instruct the client 30 to display a UI 32 that willnot allow Analysts to perform update operations. See FIG. 3E. Thoseskilled in the art will appreciate that in practice of the invention,other security rules may be defined instead of, or in addition to, theillustrated security rule, shown by way of non-limiting example.

FIGS. 3A-3E, referenced above, depict a user interface (UI) 32 executingon client digital data processing device 30 (e.g., personal computer,workstation, etc.). In the illustrated embodiment, the client device 30provides a user interface 32 for interacting with stored digital data(e.g., data create, read, update and delete operations, and so forth).As shown, the user interface 32 includes a variety of fields, e.g.,“SSN” field 32 a, discussed above, and several “buttons” 32 b-32 e forperforming “CRUD” operations (e.g., via HTTP methods, RPC, orotherwise). Although user interface buttons are only included for datacreate 32 b, read 32 c, update 23 d and delete 32 e operations, thoseskilled in the art will appreciate that in practice of the invention theUI 32 may include other interface options instead of, or in addition to,the interface buttons shown here by way of non-limiting example.

FIG. 4 depicts an exemplary operation of a system for storing andretrieving digital data (e.g., RDF or other semantic data) according toone practice of the invention. The illustrated sequence of steps is justone of many with which the invention may be practiced. Thus, it may bepracticed with a greater or lesser number of steps than those shownhere, ordered as shown in the drawing or otherwise.

By way of overview, as discussed above, a system executing in accordherewith stores and retrieves digital data (e.g., RDF or other semanticdata) in accord with a model 25, or, more particularly, in accord withan ontology 21 (e.g., defined via the ontology editor 21) and a set ofconstraints 24 (e.g., defined via the SEF 23). This storing andretrieving of digital data can include, for example, creating, reading,updating and deleting (CRUD) data from a data store 60 via a GraphicalUser Interface (GUI) 32, or other User Interface (UI), e.g.,command-line, etc.

Unlike other data storage and retrieval systems currently available inthe prior art (e.g., in which developers APIs supplied with the systemsto write “one-off” applications), the system of the illustratedembodiment allows a user 20 (e.g., developer, analyst, etc.) to create amodel 25 that defines how user's (e.g., client 30) interact with data(e.g., RDF data in data store 60). Thus, for example, as clientrequirements change (e.g., increased security on UPDATE operations), theuser may easily edit the model 25, rather than having the originaldevelopers either extensively modify the existing application, or writean entirely new application from scratch.

FIG. 4 depicts a sequence of steps for performing storage and retrievaloperations (e.g., CRUD operations, etc.) in a system according to theinvention. In steps 400-430, a developer, administrator, analyst, etc.(collectively, “analyst”) builds and deploys a software platformproviding CRUD editing capabilities to a client, as discussed above.More particularly, in the illustrated embodiment, an analyst executesthe ontology editor 21 (e.g., on the digital data processor 20 orotherwise). See step 400. The illustrated ontology editor 21 creates anontology 22 that defines a structure of data (e.g., RDF data stored indata store 60, discussed below). This may include a text editor, aninterpreter/compiler, libraries, or otherwise—all of the type known inthe art, albeit as adapted in accord with the teachings hereof. In theillustrated embodiment, the editor 21 creates the ontology 22 with theWeb Ontology Language (OWL), although in other embodiments the editor 21may use other ontology-definition languages, as well.

In step 410, the analyst executes the SEF 23 (e.g., on the digital dataprocessor 20, or otherwise) to define user roles (e.g., Supervisor,Analyst, Administrator, etc.), security rules, validators, defaultvalues, field masking, and/or other constraints 24 (collectively,“constraints”) that are applied to data characterized by the ontology22. In the illustrated embodiment, the constraints 24 are defined inXML, although in other embodiments it may be otherwise. The SEF 23generates a semantic model 25 (or simply, “model”) by combining theontology 22 and constraints 23 into a cohesive file (or set of files).Accordingly, in the illustrated embodiment, the model 25 is the“foundation” for providing CRUD capabilities to the client 30.

In step 420, the SEF 23 generates and transmits database code 27 to thedatabase server 50. In the illustrated embodiment, the code 27facilitates interaction between the database server 50 and the datastore 60. In step 430, the SEF 23 generates and transmits the clientcode 26 (e.g., Adobe Flex) to the UI Server 40 for creating the clientinterface 31 displayed on the client device 30 (e.g., via a webbrowser), although in other embodiments, the code 26 may be transmitteddirectly to client device 30.

In the illustrated embodiment, as discussed above, the SEF 23 displays auser interface 100 for the analyst to customize and generate the model25. More particularly, the analyst may add, remove, update, or otherwisedefine the constraints 24 via a set of graphical menus 110-170, and theSEF 23 generates code 24 a corresponding to those constraints. Asdiscussed above, those constraints 24 can include, for example, defaultvalues 140, field masking 150, validators 160, and security rules 170,just to name a few.

In step 440, the client device 30 sends a request to the UI server 40for an interface 32 (e.g., a web page) for interacting with data in thedata store 60. By way of non-limiting example, the client 30 may requesta web page that provides form-fillable fields and graphical buttons forperforming CRUD operations, although the client 30 may request otherinterfaces, as well (e.g., a log-in screen, etc.). In the illustratedembodiment, the interface 32 is generated from UI code 33 comprising theclient code 26, HTML, and other web technologies known in the art, suchas JavaScript, etc, although in other embodiments it may be otherwise.

In step 450, the UI server 40 generates the UI code 33 that will displaythe UI 32 requested in step 440. In the illustrated embodiment, the UIserver 40 generates the code 33 from the model 25 and the client code26, and comprises a combination of Adobe Flex code, HTML, JavaScript,XML, etc., although it may also include other components instead of, orin addition to, the aforementioned technologies (e.g., programminglibraries, modules, etc.). Although in the illustrated embodiment, theUI server 40 generates the UI code 33, in other embodiments the dataprocessor 20 may generate such code 33 itself, e.g., via the SEF 23, andthe UI server 40 may only store and execute that code 33.

In step 460, the UI server 40 sends the UI code 33 to the client 30(e.g., via LAN/WAN 70), and the client 30 renders the user interface 32(e.g., a web-fillable form with blank data fields) from that code 33.Those skilled in the art will appreciate that one or more firewalls 41are employed to insure that the UI code 33, or other data, is notintercepted (e.g., by hackers, sniffers, etc.). Moreover, to furtherinsure system security and integrity, in the illustrated embodiment onlynecessary code and data is sent to the client, e.g., as defined by themodel 25, discussed above. Although not shown here, in otherembodiments, the system may employ additional firewalls or othersecurity measures commonly known in the art of information security,albeit as adapted in accord with the teaching hereof.

In step 470, the client sends a data identifier (e.g., a recordidentifier) to the UI server 40 for processing by the UI server 40and/or database server 50, as discussed below. By way of non-limitingexample, the data identifier may be a “Customer ID” that has dataattributes (e.g., last name, date of birth, height, social securitynumber, etc.) associated with fields of the interface 32. In step 480,the UI server 40 sends a transaction request to the database server 50to retrieve data associated with the identifier from the data store 60.In step 490, the database server 50 processes the request of step 480and retrieves the data from the store 60 (e.g., via SQL, SPARQL, etc.).In steps 500-510, the retrieved data is sent to the UI server 40 andthen to the client 30 for display in the UI 32. See, for example, FIG.2A.

In step 520, the client 30 inputs data and initiates a selected CRUDoperation (e.g., via the user interface 32). For the purposes of thisdiscussion, we will assume that the interface 32 looks similar to thatillustrated in FIGS. 2A-2E, and the user wishes to input a socialsecurity number data value into a social security number data fields(i.e., perform a data create operation). However, those skilled in theart will again appreciate that these steps are shown merely by way ofnon-limiting example, and may include other steps in addition to, orinstead of, the steps discussed above (e.g., other CRUD operations maybe performed, other data values may be input/edited, etc.).

In step 530, the client 30 performs a “client-side” validation on thedata inputted in step 520. In the illustrated embodiment, client-sidevalidations are executed by the UI code 33, and are defined in theclient code 26, although in other embodiments they may be executedand/or defined otherwise (e.g., in the model 25). By way of non-limitingexample, client-side validations can include, among others, theconstraints discussed above (e.g., minimum string length, maximum stringlength, etc.), and if any validation fails, the user is warned, e.g.,via a pop-up window displayed in the UI 32 or otherwise. Thus, forexample, if the client code 26 required a validation that a socialsocial security number data value must have a minimum and maximumcharacter length of nine characters, and the user failed to input anine-character social security number data value, the user would bewarned (see, e.g., FIG. 3D), and prompted to re-enter the number. Thisprocess will be repeated until all validations are passed. Those skilledin the art will appreciate the above example is just that—an example,and in practice of the invention other validations may be performed inaddition to, or instead of, the validation described above.

In step 540, the inputted data (e.g., the social security number in thisexample), is sent to the UI server 40 (e.g., via LAN/WAN 70) for“server-side” validations (step 550). As discussed above, thesevalidations are defined in the model 25 and executed by code generatedtherefrom by the UI server 40. They can include, for example, a check toinsure that the social security number is a string containing exactlynine digits (e.g., in the event that such an error was not caught by theclient-side validations in step 530). By way of further example, if theinputted data does fail this validation, or any other validations (e.g.,as defined by the model 25 or otherwise), the UI server 40 may generatea server-side exception which can, for example, terminate the currenttransaction, or it can be sent to the client 30 in the form of agraphical warning (see step 560).

In step 560, a warning is sent from the UI server 40 to the client 30 ifan exception (or other type of error) is thrown or detected in thevalidation step 550. By way of non-limiting example, such an error canbe generated as a result of an inputted social security number that isnot exactly nine digits in length (e.g., as described above in step530), or as otherwise required by the model 25. In the illustratedembodiment, the warning can be a pop-up window (e.g., of the type shownin FIG. 3D), etc. In step 570, the client can re-input data (e.g., a newsocial security number data value) that will be re-validated in step 580(e.g., as described above in step 550). This process will be repeateduntil the validation step 580 is successfully completed (i.e., withoutany detected exceptions or errors).

In step 590, the validated data (e.g., the new social security numberdata value) is sent to the database server 50 for processing (e.g., viaa LAN/WAN connection, cabled connection, etc.). In step 600, thedatabase server 50 processes the transaction, e.g., associates theinputted data value with the social security number attribute of thedata identifier (e.g., Customer ID “555555”) in the data store 60. Thiscan be accomplished by a variety of techniques pursuant to the dataformat of the store 60. Thus, for example, SPARQL may be used for an RDFdata store, SQL for a relational database, and so forth. In thisexample, the code (whether SPARQL, SQL, etc.) for associating theinputted data value with the social security number attribute of thespecified data identifier (e.g., Customer ID “555555”) comprises thecode 27 generated by the SEF 23 (as discussed above and shown in FIG. 1)and stored/executed on the database 50, (as discussed above and shown inFIG. 1), although in other embodiments it may be otherwise.

In step 610, the database server 50 returns the the result of theprocessed transaction (e.g., completed, failed, etc.) and the processeddata (e.g., a confirmed created data value, a confirmed updated datavalue, etc.) to the UI server 50. In the illustrated embodiment, failedtransactions generate a warning by the database server 50 or UI server40 (e.g., as described in step 560) that can be sent to the client 30,administrator, other user, etc.

In step 620, the data (e.g., social security number) is sent to theclient 30 for display in the UI 32, subject to any constraints definedby the model 25. Thus, as shown here by way of non-limiting example, amasking constraint may be applied to the social security number datavalue before it is sent to the client 30 for display in the UI 32. Inthe illustrated embodiment, masking will hide a selected portion of thedata value (or the entire data value) on the UI server 40 (i.e.,“server-side” masking), and the full data value (e.g., social securitynumber) will never be sent to the client 30 or be displayed in the UI32. Rather, the UI server 40 will replace selected portions (e.g., oneor more characters) of the data value with mask values for display inthe UI 32 (e.g., an asterisk for each of the masked characters in thedata value). See, e.g., FIG. 3C. Of course, those skilled in the artwill appreciate that other types of masking may be applied in this step,as well as other constraints in addition to, or instead of, maskingconstraints.

Described above are methods and apparatus meeting the desiredobjectives. Those skilled in the art will appreciate that theembodiments herein are merely examples of the invention and that otherembodiments incorporating changes therein fall within the scope of theinvention, of which we claim:

1. A digital data processing system, comprising: A. a first digital dataprocessor coupled to (i) a second digital data processor and (ii) a datastore, B. a model comprising an ontology and a set of constraints, C.the first digital data processor any of creating, reading, updating anddeleting data from the data store based on code generated from the modelby said first digital data processor. 2.-57. (canceled)